IP Multimedia services provide a dynamic combination of voice, video, messaging, data, etc, within the same session. This has lead to a growth in the numbers of basic applications and the media which it is possible to combine, leading to a growth in the number and variety of services offered to the end users—so-called “combinational IP Multimedia” services.
IP Multimedia Subsystem (IMS) is the technology defined by the Third Generation Partnership Project (3GPP) to provide Internet Protocol (IP) Multimedia services over mobile communication networks. IMS provides key features to enrich the end-user communication experience through the integration and interaction of services both person-to-person (client-to-client) as well as person-to-content (client-to-server) communications over an IP-based network. The IMS makes use of the Session Initiation Protocol (SIP) to set up and control calls or sessions between user terminals (or user terminals and application servers). The Session Description Protocol (SDP), carried by SIP signalling, is used to describe and negotiate the media components of the session.
FIG. 1 illustrates schematically how the IMS fits into the mobile network architecture in the case of a General Packet Radio Service (GPRS) access network. Although numerous network entities, or nodes are depicted, only those relevant to the present discussion have been assigned reference numerals. As shown in FIG. 1 control of communications occurs at three layers (or planes). The lowest layer is the Connectivity Layer 1, also referred to as the bearer plane and through which signals are directed to/from user equipment (UE) accessing the network. The entities within the connectivity layer 1 that connect an IMS subscriber to IMS services form a network that is referred to as the IP-Connectivity Access Network (IP-CAN). The GPRS network includes various GPRS Support Nodes (GSNs). The middle layer is the Control Layer 4, and at the top is the Application Layer 6. Media Gateways (MGWs) 10 provide a translation function that converts media streams between networks operating different technologies or with different transport protocols.
The IMS 3 includes a core network 3a, which operates over the middle, Control Layer 4 and the Connectivity Layer 1, and a Service Network 3b. The IMS core network 3a includes nodes that send/receive signals to/from the GPRS network via the GGSN 2 at the Connectivity Layer 1 and network nodes that include Call/Session Control Functions (CSCFs) 5. The CSCFs 5 operate as SIP proxies within the IMS in the middle, Control Layer 4. Other IMS core network entities shown include a Media Resource Function Controller (MRFC), a Border Gateway Control Function BGCF and a Media Gateway Control Function, (MGCF). The IMS also includes a Home Subscriber Server (HSS) 5a, which supports the IMS nodes that handle calls and performs authentication and authorization of the user. The top, Application Layer 6 includes the IMS service network 3b. Application Servers (aSs) 7 are provided for implementing IMS service functionality.
As shown in FIG. 1, User Equipment (UE) can access the IMS by attaching to an access network and then over the Connectivity Layer 1, which is part of a PS domain. If the UE attaches to the network via a PS access network, such as a 3GPP Long Term Evolution (LTE) access network, an IMS session can be set up by the UE using SIP signalling. However, many existing access networks operate only using CS technology, and a UE may also access IMS services via a CS domain 8. Although the CS domain 8 will not handle SIP, procedures are well established for dealing with the provision of media and services between the IMS and a UE using a CS access. In a CS access, A UE attaches via a Radio Access Network (RAN—such as a Global System for Mobile Communications (GSM) Edge RAN, GERAN), which is communicatively coupled to a Mobile Switching Centre (MSC) Server 9.
There are many occasions when during a call/session it is required to transfer or hand over the call/session from one access network to another. There are a variety of factors that are used to determine when a call needs to be handed over to another access network, but these are not particularly relevant to the present discussion. Generally, the access network determines, based on the cells for which the UE reports measurements, when the conditions arise that require a request to be made to the core network for the call to be handed over.
Single Radio Voice Call Continuity (SRVCC) is described in 3GPP TS 23.237 V11.2.0 (2011-09), referred to hereafter as TS 23.237, and 3GPP TS 23.216 V11.2.0 (2011-09), referred to hereafter as TS 23.216. These specify procedures for handover of a call from a PS access to a CS access (e.g. transfer of a Voice-over-IP, VoIP, IMS session from an evolved Universal Mobile Telecommunications System (UMTS) Terrestrial RAN, E-UTRAN, to a UTRAN/GERAN).
When a UE performs a SRVCC handover, the MSC Server 9 performs certain actions related to allocation of resources for the call in the target CS access network (i.e. in a Base Station Controller, BSC or a Radio Network Controller RNC), which it needs to do before it starts interacting with the IMS. For example, a codec is selected for the call during the CS access. Although the MSC Server 9 also obtains information from a Mobile Management Entity (MME) on the codecs supported by the UE, it does not know which of these supported codecs is actually being used by the UE on the PS access (e.g. LTE or High Speed Packet Access, HSPA). This may result in a different codec being selected for the session on the CS access than was being used on the PS access. As a consequence there may be degradation of the speech quality, and inefficient use of resources, due to transcoding that has to be performed by a MGW after the SRVCC handover.
Another problem that arises with current procedures is that the MSC Server 9 seizes a Mobile-Media Gateway (M-MGW) that it will use for the call. Other Media Gateways (MGWs) may also be seized (or allocated), for example the Access Transfer Control Function (ATCF)—an IMS entity that controls access transfers—may seize an Access Transfer Gateway (ATGW), and in roaming scenarios the Interconnection Border Control Function (IBCF) may seize a Transition Gateway (TrGW), which is yet another gateway node. The seizing of all these separate nodes is inefficient and sub-optimal, especially as they all perform the same basic functions (with only a few differences). In the following discussion, the term MGW is used to refer generally to any of these nodes, except where there is a specific need to differentiate between the roles, where the individual gateway names, M-MGW, ATGW or TrGW, will be used.